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Problem  Definition 


•  Need  for  U.S.  Government  Protection  Profile 
for  Separation  Kernels  in  Environments 
Requiring  High  Robustness  (SKPP) 

-  Various  products  forthcoming 

-  High  Robustness  -  uncharted  Common  Criteria 
territory 

•  Preliminary  Analysis:  Protection  Profile  (PP) 
requires 

-  CC-oriented  description  of  TOE  abstractions 

-  Extensions  to  several  Common  Criteria  requirements 

-  Extrapolation  from  existing  guidance  and  examples 

•  E.g.,  US  scheme  medium  robustness  CIM 

•  Medium  Robustness  MLS  OS  PP  draft 
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General  Separation  Kernel  Characteristics 


•  Separation  Kernel  (Rushby,  1981,  etc.) 

•  Manages  computing  and  communication  resources 

-  Self-protecting 

•  Creates  abstractions  of  resources  for  export  at  SK 
interface 

•  SK  Partitions  resources  into  policy  equivalence  classes* 

•  Controlled  separation  of  equivalence  classes 

-  No  interaction  between  classes  unless  explicitly  allowed 


*  These  equivalence  classes  are  sometimes  also  called  “partitions” 
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General  SK  Characteristics 


•  Taxonomy  of  SK  runtime  resources 

-  Internal 

•  Used  for  implementation  of  kernel 

-  Exported 

•  Subjects 

-  Programs,  asynchronous  devices,  etc. 

•  All  other 

-  Memory,  files,  devices,  buffers,  volumes  etc. 

-  “objects” 
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Specific  SK  Characteristics 


•  Limited  functionality  expected 

-  E.g.,  embedded  systems 

•  No  runtime  user  interface 

-  No  user  identification  and  authentication 

•  Static  runtime  configuration  of  security  policy  and  resource 
allocation 

-  Specified  in  “TSF  configuration  data” 

-  Exceptions  allowed  for  exigencies 

•  Support  privileged  subjects 

-  Limit  access  to  privileged  interfaces 

•  Support  trusted  delivery,  trusted  recovery 

•  Export  or  store  audit  records 

-  At  least  one  is  required 
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Evaluation  Target 


•  EAL6 

•  +  Formal  Security  Policy  Model 

•  TOE  Components 

-  TSF 

•  Software 

•  Hardware  base 

-  Initialization  mechanism 

-  Configuration  mechanism 

-  Delivery  and  recovery  mechanisms 
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SKPP  High  Robustness  Issues 


•  Principle  of  least  privilege  (PoLP) 

-  All-or-nothing  security  cannot  be  high  robustness 

•  Dynamic  configuration 

-  On-the-fly  security  policy  changes  may  be  intractable  to 
analyze  with  respect  to  the  separation  of  equivalence 
classes  (e.g.,  Harrison  et  al,  1976) 

•  Hardware  as  part  of  the  TSF 

-  A  classic  third-party  assurance  composition  problem 
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Principle  of  Least  Privilege  (PoLP) 


•  PoLP  (reviewed  in  Saltzer,  Schroeder, 

1975) 

-  Mechanisms  should  have  no  more  privilege 
than  what  is  necessary  to  perform  the  actions 
for  which  they  were  designed 

•  PoLP  Applied  to  SKPP 

-TSF  must  have  capability  to  restrict  subjects’... 

•  access  to  privileged  operations 

•  access  to  resources  within  a  partition 

-TSF  must  be  structured  to  restrict  privileges  of 
internal  modules/functions 
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Least  Privilege  in  FDP_ACC 


•  Use  Case: 

-  TSF  supports  multiple  heterogeneous  subjects  in  a 
partition 

-  TSF  must  discern  between  those  subjects  for  the 
purpose  of  information  flow  control 

•  FDP_ACC: 

-  TSF  may  allow  an  operation  of  a  subject  on  an  exported 
resource  only  if: 

•  Partition-to-Partition  flow  rule  explicitly  authorizes  operation 

•  S uhject-to-Reso urce  flow  rule  explicitly  authorizes  operation 
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Least  Privilege  in  ADV_ARC/ADV_INT 


•  PoLP  advantages  for  design  and  internal  structure 

-  Affords  simplicity  to  implementation 

-  Coupled  with  layering  and  minimization,  increases 
confidence  in  analysis  of  TSF  correctness 


•  ADV_ARC;  requires  justification  that  TSF  design 
achieves  PoLP 

•  AD V  I NT:  requires  PoLP  to  be  applied  to  all  TSF 
modules/functions 
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Exceptions  to  PoLP 


•  FDP_ACC  allows  certain  PoLP  “exceptions” 

-  Configurations  where  subject-resource  interaction  is 
“policy-equivalent”  to  that  of  their  partition 

•  Interaction  between  single-subject  and  single-resource 
partitions 

-  Only  one  subject  in  subject’s  partition 

-  Only  one  exported  resource  in  resource’s  partition 

•  Homogeneous  functionality  of  subjects  in  a  partition 

-All  subjects  in  subject’s  partition  require  same 
operation  on  all  exported  resources  in  resource ’s 
partition 
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SK  Configuration 


•  Static  Configuration  SK 

-  Initial  configuration  data  determines  runtime  behavior 

•  All  resource  allocations 

-  Time  -  e.g.,  CPU  time  slices 

-  Space  -  e.g.,  per-partition  memory  regions 

•  All  allowed  information  flows 

-  Ideal  for  embedded  systems  and  security  research 

•  Simple  design  and  implementation 

•  Evaluatable  size 

-  Provides  fundamental  security  service:  separation 

-  Building  block  for  more  complex  systems 

-  Assurance  issue  with  con  figuration-data  based  policy 
mechanism: 

•  Ensure  resulting  security  policy  reflects  the  organization ’s 
intent 
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Dynamically  Configurable  SK 


•  Problem  scenario 

-  Failure  of  a  peripheral  device  in  a  mission  critical 
application,  or 

-  Overriding  environmental  security  conditions 

•  Desirable  for  TOE  to  be  able  to  change  its 
configuration 

•  SKPP  allows  TOE  to  change  resource  allocations 
and  policy  rules  during  runtime 

-  Several  problems 
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Dynamic  Configuration  Problems 


•  Continuity  of  security  across  a  policy  transition 

-  Undefined  security  during  transition? 

-  Undefined  combinations  of  policies  after  transition? 

•  Arbitrary  changes  are  hard  to  understand  w.r.t. 
policy 

-  Formal  models  often  have  static  attributes  because  of 
this 

•  Approach: 

-  Limit  how  policy  may  change 

-  Four  hierarchical  modes  of  change  defined 
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SKPP  Dynamic  Configuration  Options 


1.  Off-line  transitions  and  pre-loaded  configurations 

-  Allows  complete  removal  of  previous  security  state 

-  Allows  pre-analysis  of  subsequent  security  policies 

-  Triggered  by  privileged  subject  or  offline  actions 

-  Assurance  issue:  TSF  must  ensure 

•  Only  authorized  subject  may  request  configuration  change 

•  TOE  fully  and  properly  executes  the  change  request 

2.  On-line  transitions  and  pre-loaded,  configurations 

-  Allows  dynamic  change  of  configuration 

-  Additional  assurance  issue:  TSF  must  continuously  maintain 
secure  state 

•  Before ,  during  and  after  the  configuration  change 
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SKPP  Dynamic  Configuration  Options 

(continued) 


3.  On-line  transitions  and  limited  configuration  changes 

-  Changes  limited  by  static  rules  enforced  by  TSF 

-  Additional  assurance  issue: 

•  Ensure  ad  hoc  policy  change  requests  are  consistent  with 
organization ’s  policy  intents 

4.  On-line  transitions  and  arbitrary  configuration  changes 

-  Additional  assurance  issue: 

•  TOE  vendor  must  provide  convincing  definition  of  “secure 
transition”  in  SFP  model 


•  Options  3  and  4  are  beyond  the  scope  of  the  SKPP 

-  Will  require  an  ST-  rather  than  PP-based  evaluation 
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SKPP  DC  Requirements 


Details  of  SKPP  functional  and  assurance 
requirements  for  dynamic  configuration  are 

ST-specific 
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SKPP  Transition  to  CC  V3.0 


•  SKPP 

-  Developed  to  be  conformant  to  CC  V2.2 

•  CC  V3.0  significantly  different 

•  FDP_ACC  simpler  than  FDPJFF/IFC 

•  Challenges  include 

-  Hardware  assurance  undefined 

-  Non-user  Security  Attributes 

-  Covert  Channel  Analysis  by  developer 
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Security  Attributes  Binding 


•  SKPP  requires  binding  of  security  attributes 
to  exported  resource  when  resource  is 
created 

•  Two-step  process:  registration  and 
initialization 

—  FIA_URE;  TSF  must  store  attributes  of  exported 
resources  in  identified  internal  resources 
•  e.g.,  kernel  structures 

—  FIA_ISA:  TSF  must  bind  (those)  attributes  to 
corresponding  exported  resources  when  resource  is 
created 
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Summary 


•  High  Robustness  Requires 

-  PoLP 

-  Control  of  Dynamic  Re-Configuration 

•  Common  Criteria  Version  3.0  transition 

-  Most  SK  requirements  fit  into  existing  families 

-  A  few  new  explicit  requirements  required  to  cover  scope 
of  TOE 
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